replace `--override.prague` with `--override.osaka`

Signed-off-by: jsvisa <delweng@gmail.com>

For no apparent reason, KV stores were getting wrapped in `nofreezedb`
first and then in `freezerdb`.

core.BlockChainConfig.VmConfig is not a pointer, so setting the Tracer
on the `vmConfig` object after it was passed to options does *not* apply
it to options.VmConfig

This fixes the issue by setting the value directly inside the `options`
object and removing the confusing `vmConfig` variable to prevent further
mistakes.

This is to avoid compatibility issues with mismatched glibc versions
between the builder and deployment target.

Fixes #32102

Fix the issue after initial snap sync with `gcmode=archive` enabled.

```
NewPayload: inserting block failed       error="history indexing is out of order, last: null, requested: 1"
```

---------

Signed-off-by: Delweng <delweng@gmail.com>
Co-authored-by: Gary Rong <garyrong0905@gmail.com>

The address filter was never checked against a maximum limit, which can
be somewhat abusive for API nodes. This PR adds a limit similar to
topics

## Description (AI generated)

This pull request introduces a new validation to enforce a maximum limit
on the number of addresses allowed in filter criteria for Ethereum logs.
It includes updates to the `FilterAPI` and `EventSystem` logic, as well
as corresponding test cases to ensure the new constraint is properly
enforced.

### Core functionality changes:

* **Validation for maximum addresses in filter criteria**:
- Added a new constant, `maxAddresses`, set to 100, to define the
maximum allowable addresses in a filter.
- Introduced a new error, `errExceedMaxAddresses`, to handle cases where
the number of addresses exceeds the limit.
- Updated the `GetLogs` method in `FilterAPI` to validate the number of
addresses against `maxAddresses`.
- Modified the `UnmarshalJSON` method to return an error if the number
of addresses in the input JSON exceeds `maxAddresses`.
- Added similar validation to the `SubscribeLogs` method in
`EventSystem`.

### Test updates:

* **New test cases for address limit validation**:
- Added a test in `TestUnmarshalJSONNewFilterArgs` to verify that
exceeding the maximum number of addresses triggers the
`errExceedMaxAddresses` error.
- Updated `TestInvalidLogFilterCreation` to include a test case for an
invalid filter with more than `maxAddresses` addresses.
- Updated `TestInvalidGetLogsRequest` to test for invalid log requests
with excessive addresses.

These changes ensure that the system enforces a reasonable limit on the
number of addresses in filter criteria, improving robustness and
preventing potential performance issues.

---------

Co-authored-by: zsfelfoldi <zsfelfoldi@gmail.com>

## Summary
This PR resolves Issue #31929 by reducing log noise generated by the log
indexer after `debug_setHead` operations.

## Problem Description
When `debug_setHead` is called to rewind the blockchain, blocks are
removed from the database. However, the log indexer's `ChainView`
objects may still hold references to these deleted blocks. When
`extendNonCanonical()` attempts to access these missing headers, it
results in:

1. **Repeated ERROR logs**: `Header not found number=X hash=0x...`
2. **Log noise** that can mask other important errors  
3. **User confusion** about whether this indicates a real problem

## Root Cause Analysis
The issue occurs because:
- `debug_setHead` removes blocks from the blockchain database
- Log indexer's `ChainView` may still reference deleted block hashes
- `extendNonCanonical()` in `core/filtermaps/chain_view.go` tries to
fetch these missing headers
- The existing `return false` logic properly handles the error, but logs
at ERROR level

## Solution
This is a **logging improvement only** - no functional logic changes:

### Changes Made
1. **Log level**: Changed from `ERROR` to `DEBUG` 
2. **Log message**: Enhanced with descriptive context about chain view
extension
3. **Comments**: Added explanation for when this situation occurs
4. **Behavior**: Maintains existing error handling (`return false` was
already present)

### Code Changes
```go
// Before
log.Error("Header not found", "number", number, "hash", hash)
return false

// After  
// Header not found - this can happen after debug_setHead operations
// where blocks have been deleted. Return false to indicate the chain view
// is no longer valid rather than logging repeated errors.
log.Debug("Header not found during chain view extension", "number", number, "hash", hash)
return false
```

## Testing

### Automated Tests
- ✅ All existing filtermaps tests pass: `go test ./core/filtermaps -v`
- ✅ No regressions in related functionality

### Manual Verification
1. **Before fix**: Started geth in dev mode, generated blocks, called
`debug_setHead(3)` → **5 repeated ERROR logs**
2. **After fix**: Same scenario → **4 DEBUG logs, no ERROR noise**

### Test Environment
```bash
# Setup test environment
rm -rf ./dev-test-data
./build/bin/geth --dev --datadir ./dev-test-data --http --http.api debug,eth,net,web3 --verbosity 4

# Generate test blocks and trigger issue
curl -X POST -H "Content-Type: application/json" --data '{"jsonrpc":"2.0","method":"debug_setHead","params":["0x3"],"id":1}' http://localhost:8545
```


## Related Issues
- Fixes #31929

## Additional Context
This issue was reported as spurious error messages appearing after
`debug_setHead` operations. The investigation revealed that while the
error handling was functionally correct, the ERROR log level was
inappropriate for this expected scenario in development/debugging
workflows.

The fix maintains full compatibility while significantly improving the
debugging experience for developers using `debug_setHead`.

---------

Co-authored-by: Sun Tae, Kim <38067691+humblefirm@users.noreply.github.com>
Co-authored-by: zsfelfoldi <zsfelfoldi@gmail.com>

Sorry for not fully fixed in ethereum/go-ethereum#31761, now the log 
format of unindexing message is cleaned up, to make it consistent with the indexing message.

It should be `newPayloadV4 must only be called for prague payloads` for
the V4 payload error

use `make(map, len(txpool))` to prealloc the map for the txpool content,
to avoid the map growing in the loop.

…2021)

Towards ethereum/go-ethereum#26974

---------

Co-authored-by: Gary Rong <garyrong0905@gmail.com>

Similar to ethereum/go-ethereum#31856, remove
the not availabe shh, swarm modules in the console.

---------

Co-authored-by: Gary Rong <garyrong0905@gmail.com>

This pull request refines the filtermap implementation, defining key
APIs for map and
epoch calculations to improve readability.

This pull request doesn't change any logic, it's a pure cleanup.

---------

Co-authored-by: zsfelfoldi <zsfelfoldi@gmail.com>

closes #32120

geth cmd: `geth --dev --dev.period 5`
call: `debug.setHead` to rollback several blocks.

If the `debug.setHead` call is delayed, it will trigger a panic with a
small probability, due to using the null point of
`fcResponse.PayloadID`.

---------

Co-authored-by: Marius van der Wijden <m.vanderwijden@live.de>

1. Fix the error return format.
**todo**: ~~`bindtype` needs more complex logic to fix it.~~
`
if err != nil {
  return nil, err
}
if err == nil {
  return obj, nil
}
`
2. ~~Return pointer type object to avoid copying the whole struct
content.~~
3. Give the panic decision to the user.
4. Fix empty line at the end of function.

**TODO**: ~~fix some related test cases.~~

---------

Co-authored-by: Jared Wasinger <j-wasinger@hotmail.com>

Small update for logs when syncing with blsync. Downgrades the "latest
filled block is not available" to warn.

Co-authored-by: shantichanal <158101918+shantichanal@users.noreply.github.com>

This PR changes the trace test to block level, aiming for better
execution performance.

---------

Co-authored-by: zsfelfoldi <zsfelfoldi@gmail.com>

Improves the SSTORE gas calculation a bit. Previously we would pull up
the state object twice. This is okay for existing objects, since they
are cached, however non-existing objects are not cached, thus we needed
to go through all 128 diff layers as well as the disk layer twice, just
for the gas calculation

```
goos: linux
goarch: amd64
pkg: github.com/ethereum/go-ethereum/core/vm
cpu: AMD Ryzen 9 5900X 12-Core Processor            
               │ /tmp/old.txt │            /tmp/new.txt             │
               │    sec/op    │   sec/op     vs base                │
Interpreter-24   1118.0n ± 2%   602.8n ± 1%  -46.09% (p=0.000 n=10)
```

---------

Co-authored-by: Gary Rong <garyrong0905@gmail.com>

Some of the flags were deprecated, so try to hide them in the help
message. And move the `--vmodule` and `--logjson` flags to the
DeprecatedCategory.

…ereum-optimism#655)

Co-authored-by: Sebastian Stammler <seb@oplabs.co>

* fix!: multiply operatorFeeScalar by 100 instead of dividing by 1e6

* apply comments

* apply comments

* remove dup IsOperatorFeeFix

---------

Co-authored-by: fakedev9999 <taehoon@succinct.xyz>

…m-optimism#697)

…ism#694)

…ime (ethereum-optimism#704)

…used (ethereum-optimism#705)

* core: add gauge metric for block gas used and blob gas used

This can be used to track the DA footprint per block

* encapsulate OPStack additions into new file and function

* add histogram metrics for (blob)GasUsed

* update fork.yaml

* typos

…thereum-optimism#707)

This introduces more realistic limits on accelerated precompiles for the Jovian hard fork.

* core/types: Move receipt tests OP diff to separate file

* core/types: Populate Jovian receipt fields

Implements a migration path for the blobpool slotter

---------

Co-authored-by: lightclient <lightclient@protonmail.com>
Co-authored-by: lightclient <14004106+lightclient@users.noreply.github.com>
Co-authored-by: Gary Rong <garyrong0905@gmail.com>

Sets the fusaka, bpo1, bpo2 timestamps for mainnet
see: https://notes.ethereum.org/@bbusa/fusaka-bpo-timeline

…lop/fusaka-mainnet

params: set osaka and BPO1 & BPO2 mainnet dates (#33063)

…ptimism#718)

This pull request addresses the corrupted path database with log
indicating:
`history head truncation out of range, tail: 122557, head: 212208,
target: 212557`

This is a rare edge case where the in-memory layers, including the write
buffer
in the disk layer, are fully persisted (e.g., written to file), but the
state history
freezer is not properly closed (e.g., Geth is terminated after
journaling but
before freezer.Close). In this situation, the recent state history
writes will be
truncated on the next startup, while the in-memory layers resolve
correctly.
As a result, the state history falls behind the disk layer (including
the write buffer).

In this pull request, the state history freezer is always synced before
journal,
ensuring the state history writes are always persisted before the
others.

Edit: 
It's confirmed that devops team has 10s container termination setting.
It
explains why Geth didn't finish the entire termination without state
history
being closed.

https://github.com/ethpandaops/fusaka-devnets/pull/63/files

Co-authored-by: rjl493456442 <garyrong0905@gmail.com>

…-v1.101603.4